Beware of the Past

Undiscovered things

A few days ago, Jolyon Smith warned Delphi users to Mind the Gap(s). The warning is about how assigning specific ordinal values to enum members defeats the RTTI system. He writes:

This is what I love about Delphi. After almost 15 years of Delphi’ing there’s still new things to learn, and I don’t just mean new features in the latest releases. I mean, basic, fundamental things that have been there for years, just undiscovered (by me).

I fully agree, and today it was my turn to find such an "undiscovered (by me)" thing in Delphi.

I received a bugreport about a simple edit screen not opening due to an EVariantInvalidArgError exception. Strange, because the exception seemed to be in straightforward code that has been in production for twelve odd years, and hasn't been changed lately (sound familiar?).

Examining the code

Leaving out the code that checks for invalid inputs, the remaining code basically boils down to this:

var
  EditText: string;
  StoredValue: Variant;
begin

  // example user input from the edit screen
  EditText := '16-9-2009';

  ...

   // store the date value when the edit screen closes
  StoredValue := StrToDate(EditText);

  ...

  // convert the stored value to string when the edit screen opens
  EditText := VarToStr(StoredValue); <= EVariantInvalidArgError reported ???

end;

Not much too worry about codewise it seems. And I couldn't reproduce the error using my development data. Still, the error was readily reproducible in the production environment, so I looked at the production database record to see what value was causing the trouble. It turned out to be '01-01-0010'. Clearly a typo by a user that wanted to write '01-01-2010'. A typo maybe, but a valid date nevertheless. And besides, if there really was anything fishy about that date, I would expect the exception to be raised when trying to store the value in the variant, not when converting the variant back to a string. What was happening?

Use the source, Luke

Well, if it isn't me, it must be Delphi. So I looked through the code in the variants unit and after a while it started to make sense. It turns out that Delphi uses an OS function (VarBstrFromDate) to cast the variant date value to a string. And this OS function only accepts dates from 01-01-100 onward, returning a E_INVALIDARG for earlier dates. So, although we can set a variant to a date before 01-01-100 and get the value from the variant as a date, we'll get an exception as soon as any implicit or explicit cast to string is performed (e.g. viewing the variant in the debugger or, the case at hand, using the VarToStr function).

Feel Good Bugs

Being a responsible Delphi citizen, I submitted the bug to Quality Central (#77783). But as this bug has "extreme corner case" written all over it, I don't think it will be fixed anytime soon. So I rewrote my code to only accept dates from 01-01-100 onwards, and treat all dates before that as invalid. It was a simple change because the application had centralized input checking. Another bug bites the dust!

I realize I just love this part of my work. Admittedly, there have been bugs in the past that I loved a lot less. But this was one of the "feel good" bugs. A bug that is brought to your attention by strange, apparently unexplainable symptoms. A bug that  takes some effort (but no longer than say a few hours) to localize (and is preferably localized in some else's code), and finally a bug that is easy to repair or workaround.

Can't wait for the next one.

Ending a Server Session when a Browser Window closes

The infamous "Log Off" problem

I'm working on a webapplication using Delphi 2006 and Intraweb 8. Basic stuff: the user logs on, does some database work, and then logs off. Or rather: that's how I would like it to work...

The reality is, alas, that users rarely use the provided "log off" button, but close the browser window instead. And that poses a bit of a problem: the server doesn't know the session has ended, and can't release its resources until some preconfigured time-out has occurred (half an hour in my case). Wouldn't it be great if the server could detect the closing of the browser and not keep those valuable resources tied up for an unnecessary amount of time? Well, it turns out it can, sort of.

Searching the net I found a number of solutions to the "Log Off" problem. All solutions use the unload event of the body tag. The problem is that the unload event not only fires when the browser closes, but also when a user navigates to a different page. Although some clever "hacks" exist to distinguish between closing and navigating, I haven't found one that works reliably on IE and Firefox.

An alternative solution: Getting help from the Server

Given the fact that it's a bit problematic, from within the browser itself, to differentiate between the closing of a browser window and navigating to another page, couldn't we somehow get the server to help?

The idea is simple enough:

• In the browser "unload" event we tell the server to set the session time-out to one minute.



• When the server receives a page request we reset the session time-out to its default value

This will ensure that the session time-out remains set to its default value as long as the user keeps visiting pages on our server: an "unload" event (setting the time-out to one minute) will be followed by a page request (resetting the session time-out to its default value). However, when the user closes the browser window, or navigates to some other site, the session will time-out in one minute. In these cases the "unload" event is not followed by a page request.

Now all we need is a way to call the server from within the browser unload event. Obviously some asynchronous javascript and xml could come in handy (yep, you've got it: AJAX). Well, enough talking already, let's get down to some coding.

Implementing the Browser Close Detection

The implementation I'm giving is for Delphi 2006 and Intraweb 8, but the same solution could also be implemented for other versions or web frameworks.

First let's examine the javascript that's needed to call the server from within the browser unload event. It's fairly straightforward. First we create a xmlhttp request object, and then we call the special url "endsession" on the server providing the intraweb sessionid "GAppID" as the post data. We use a POST rather than a GET command because Internet Explorer caches GET commands.

function unload(){
  if(window.XMLHttpRequest){
    var xmlhttp = new XMLHttpRequest();
  }else{
    var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
  };
  if(xmlhttp != null){
    data = "GAppID="+GAppID;
    url = GURLBase+"/endsession";
    xmlhttp.open("POST", url, false);
    xmlhttp.send(data);
  };
}

The javascript must be part of all the pages of our webapplication. A simple way of achieving this in Intraweb is to use a base form, and derive all our other pages from this base form. In the constructor code of the base form, we add the javascript, and an initialization command that links the script to the beforeunload event of the page. We're using the "onbeforeunload" event instead of the "onunload" event because we can't be sure the "onunload" event will give us enough time to fullfil the server request before the browser closes. In contrast, the "onbeforeunload" event will actually wait for the result of our server request before continuing.

constructor TFRMIWBase.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  // add javascript to the form (body left out for brevity)
  Javascript.Add('function unload(){');
  javascript.Add(<rest of body>);
  Javascript.Add('}');
  // link the javascript to the onbeforeunload browser event
  AddToInitProc('window.onbeforeunload = unload;');
end;

On the server side, we have to intercept the "endsession" url, and set the session time-out to 1 minute. In Intraweb we can achieve this by catching the url in the OnBeforeDispatch event of the servercontroller:

procedure TIWServerController.IWServerControllerBaseBeforeDispatch(Sender: TObject; Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
var
  Session: TIWApplication;
begin
  if Pos('/endsession', Lowercase(Request.PathInfo)) > 0 then
  begin
    Session := GSessions.LookupAndLock(Request.ContentFields.Values['GAppID']);
    if Assigned(Session) then
    begin
      try
        Session.SessionTimeOut := 1;
        Response.StatusCode := 200;
        Response.ContentType := 'text/xml';
        Response.Content := '<xml/>';
        Response.SendResponse;
        Handled := true;
      finally
        Session.Unlock;
      end;
    end;
  end;
end;

As expected, the "endsession" url will be called when the browser window is closed, but also when the user navigates to a new page. So it's important to reset the session time-out to its default value when a page is requested. In Intraweb we can use the OnAfterRender() event of the servercontroller:

procedure TIWServerController.IWServerControllerBaseAfterRender(ASession: TIWApplication; AForm: TIWBaseForm);
begin
  // set the current session timeout to the default servercontroller timeout
  ASession.SessionTimeOut := SessionTimeout;
end;

Adding a custom Ocl Operation to ECO

Some Background Info

To get myself acquainted with ECO and ASP.NET, I started with a simple (but long time overdue) pet project: a web based bug reporting utility. Noting fancy, mind, just a way for my users to report bugs or feature requests, and a way for myself to mark submitted reports as "opened", "closed" or, as is often the case, "needs more info". I'll be blogging about my first experiences with ECO at a later date.

In the model for my bug reporting tool, I have a "Session" class, a transient singleton with an association "CurrentUser" to a "User" class. That makes it possible to refer to the current user with the Ocl expression: "Session.AllInstances->first.CurrentUser".

Soon I realised that I was using this Ocl expression almost everywhere. Especially in the state diagram for reports, where I wanted to express transition guards like "a submitted report can only be deleted by the submitter" (Session.AllInstances->first.CurrentUser = User), or "only an administrator can mark a submitted project as open" (Session.AllInstances->first.CurrentUser.IsAdministrator). This certainly had the duplicate code smell all over it.

Asking about this in the ECO newsgroup, Oleg Zhukov suggested to define a custom Ocl operation (Thanks Oleg!).

Defining the custom operation

Defining a custom Ocl operation is not as complicated as it might seem (although it can take some time finding the relevant documentation on the net). It involves overriding two methods from the base class "OclOperationBase", and installing the derived operation into the oclservice. Let's start with the interface:

uses
  Borland.Eco.Ocl.Support;

type
  OclCurrentUser = class(OclOperationBase)
  strict protected
    procedure Init; override;
  public
    procedure Evaluate(Parameters: IOclOperationParameters); override;
  end;

Not much to see there, so on to the implementation. In the overridden Init method, we can define the number of parameters our custom Ocl operation will take and set their types. An Ocl operation always needs at least one parameter. This parameter represents the context of the Ocl operation. In this case we want to be able to use the "CurrentUser" operation with any type of context.

To complete the initialisation we call the InternalInit method, providing a name, the input parameter array, and the return type for our custom Ocl operation. In most of the examples that are floating round the net the return type is a predefined type like Support.StringType or Support.IntegerType. In our case however, we need to return a user object ("user" being a class in the model). We get the Ocl type for our user class by using the GetClassifierByType() and GetOclTypeFor() functions.

uses
  Borland.Eco.UmlRt;

procedure OclCurrentUser.Init;
var
  OCLParameters: array of IOclType;
  Classifier: IClassifier;
  OclType: IOclType;
begin
  SetLength(OclParameters, 1);
  OclParameters[0] := Support.AnyType;
  Classifier := Support.Model.GetClassifierByType(Typeof(User));
  OclType := Support.GetOclTypeFor(Classifier);
  InternalInit('currentuser', OclParameters, OclType);
end;

That's the initialisation done. Now let's get on with the evaluation. We already know the Ocl expression to return the current user, so we can just call the Ocl service to evaluate this expression.

The last task is setting the result parameter. We have two options: SetOwnedElement() and SetReferenceElement(). It's my feeling that SetOwnedElement() should be used for returning objects created by the operation itself, so that in our case SetReferenceElement() is the way to go. However, both options seem to work without problems (and documentation is lacking), so perhaps someone can shed some light on this?

uses
  Borland.Eco.ObjectRepresentation,
  Borland.Eco.Services;

procedure OclCurrentUser.Evaluate(Parameters: IOclOperationParameters);
var
  OclExpression: string;
  OclService: IOclService;
  Element: IElement;
begin
  OclExpression := 'Session.AllInstances->first.currentuser';
  OclService := Support.OclService;
  Element := OclService.Evaluate(OclExpression);
  Parameters.Result.SetReferenceElement(Element);
end;

Installing the custom operation in run- and designtime

All the above takes care of defining our custom operation. Installing it into the OclService is a breeze. Just add one line of code to the constructor of the EcoSpace:

constructor TBugReportsEcoSpace.Create;
begin
  inherited Create;
  InitializeComponent;
  // TODO: Add any constructor code here
  OclService.InstallOperation(OclCurrentUser.Create);
end;

Are we all done now? Well, almost. Although the custom operation is now known in runtime, and functions as expected, the operation is not yet known in design time. This has as a side effect that when we try to validate a model using the custom operation, we'll get an error: "undefined operation: CurrentUser". Luckily that's easily solved. By adding an attribute to our EcoSpace we can make the Ocl operation known at design time:

[EcoOclOperation(typeof(OclCurrentUser), true)]
TBugReportsEcoSpace = class(Borland.Eco.Handles.DefaultEcoSpace)
private
...

Side note: in this article about the same subject, Jesper Hogstrom remarks "Due to a very small. Minor... Miniscule... let's call it oversight, the attribute cannot be applied twice", and provides an alternative solution if you want to add more than one design time Ocl operation. It seems however that in the meantime this oversight has been fixed.

Calling the custom operation

When calling the custom operation, there are two "gotchas" to be beware of. The first is not forgetting the parentheses (i.e. calls must be in the form "CurrentUser()"), and the second is that an Ocl operation always needs a context. Although (for this operation) it doesn't matter what the context is, a context must be provided. When using the custom operation in a state diagram, the context is understood to be the class we're designing the state diagram for, so we can use "CurrentUser()" on its own. When evaluating the custom operation in code, we have to provide the context ourselves.

// context can be anything, but must be provided
Element := OclService.Evaluate('42.CurrentUser()');
Currentuser := User(Element.AsObject);

Hello World

Before even thinking about starting a Blog, I wanted to make sure I could easily post code snippets, without endlessly hassling with html markup. A mere copy and paste won't preserve formatting, so I needed a simple tool to convert source code to html, preferably giving me the possibility of doing some syntax highlighting.

The BDS 2006 community welcome page v2 (provided by Daniel Wischnewski) has a handy utility, using a CDN web service provided by John Kaster, called YAPP - Yet another pretty printer. This service allows you to format source code to HTML, directly from within the Delphi IDE. It tags reserved words, comments, quotes etc. with classnames, so you can use a stylesheet to do syntax highlighting. Exactly what I needed. Thanks guys!

To illustrate the point, here is the classic and unavoidable "Hello World" example (in Delphi):

uses
  Dialogs;

procedure HelloWorld;
begin
  // superfluous comment
  ShowMessage('Hello World');
end;

It seems I've overcome my first Blogging hurdle. Ready to go on to even greater and more meaningful things. I'll keep you posted.

O, and if you're wondering where to put your syntax highlighting styles: log in to blogger, and navigate to menu option "customize", tabsheet "template", menu option "edit html". Have fun!